FireWall-1 Architecture and Administration
[Top]
[Prev]
[Next]
[Bottom]
The Technology
The privacy, authenticity and
integrity of communications can be ensured by encrypting data as it passes
through the network. This section describes the technology employed by
FireWall-1's Encryption feature.
Basic Definitions
Encryption
Encrypting a message modifies ("encrypts")
its text ("plaintext" or "cleartext") so that the encrypted text ("ciphertext")
can only be read ("decrypted") with the aid of some additional information
("key") known only to the sender and the intended recipient.
Authentication
Authenticating a message verifies the
authenticity of both the sender and the message, checking for possible tampering
and interference with the communication.
Encrypting a Message
The simplest way to encrypt a
message is by using a secret key, one that both encrypts and decrypts the
message. Ensuring the key's secrecy is critical, since anyone who knows the key
can decrypt and read the message.
Figure 4-1 Encrypting and decrypting with a secret
key
Sharing a Secret Key
Secret key encryption is simple and
fast, but there are two problems associated with its use:
- Direct face-to-face negotiation may be impractical or unfeasible, and the
correspondents may have to agree on a key by mail or telephone or some other
relatively insecure means.
Public Key Distribution System
Public key systems, where
each correspondent has a pair of keys, can solve both of these problems.
A key pair is composed of two mathematically related keys: a
public key known to everyone, and a private key known only to its owner.
The Diffie-Hellman public key distribution system can be used
to share a secret key without communicating any secret information, so a secure
channel is not required for the key exchange. Also, under this system, only one
key pair needs to be managed for each correspondent. Once the correspondents
have computed the shared secret key, they can use it to encrypt communications
between them.
Diffie-Hellman Scheme
Under the Diffie-Hellman scheme, a
secret key is agreed on and exchanged as follows (Figure
4-2 ), using the private and public parts of Alice's and Bob's
Diffie-Hellman keys.
- 1. Bob gets Alice's public key and performs a calculation involving his
own private key and Alice's public key.
- 2. Alice gets Bob's public key and performs a calculation involving her
own private key and Bob's public key.
- The results of both calculations are the same, and this result serves as
the secret key. In this way, a secret key can be agreed on without any secret
information being communicated. There is no opportunity for an eavesdropper to
determine the secret key.
Figure 4-2 Agreeing on a Secret Key by Exchanging
the Public Parts of Diffie-Hellman Keys
Certifying a Public Key
If Alice and Bob obtain each
other's public keys over an insecure channel, such as the Internet, they must be
certain that the keys are genuine. Alice cannot simply ask Bob for his public
key, because there is the danger that Mallory might intercept Alice's request
and send Alice his own key instead. Mallory would then be able to read all of
Alice's encrypted messages to Bob.
For this reason, there must be a trusted third party, known
as a Certificate Authority, from whom Alice can reliably obtain Bob's public
key, even over an insecure channel.
The CA certifies Bob's public key by generating a certificate
for the key. Anyone retrieving Bob's public key verifies the certificate as
proof of the key's validity, that is, that it really is Bob's key.
Digital Signatures
A digital signature acts as proof of
the sender's identity and the message's integrity. Digital signatures can be
created using a public key encryption system, such as RSA.
The CA signs the certificate with a digital signature
computed from its own private key. Using the CA's public key, anyone can verify
the signature. It is computationally unfeasible to forge the digital signature.
If a message or certificate is sent together with its digital
signature, then any tampering will immediately become apparent upon verifying
the signature.
Encryption Schemes
Elements of an Encryption Scheme
An encryption scheme
consists of the following elements:
- 1. an encryption algorithm for encrypting messages
- 2. an authentication algorithm for ensuring integrity, that is, that
messages have not been tampered with
- 3. a key management protocol for generating and exchanging keys
Encryption Schemes Supported by FireWall-1
FireWall-1
supports three encryption schemes:
- 1. FWZ, a proprietary FireWall-1 encryption scheme
- FWZ is described in "FWZ
(FireWall-1) Encryption Scheme" .
- 2. Manual IPSec
- Manual IPSec is an encryption and authentication scheme that uses fixed
keys. Manual IPSec is described in "Manual
IPSec Encryption Scheme" .
- 3. SKIP (Simple Key-Management for Internet Protocols)
- SKIP, developed by Sun Microsystems, adds two features to Manual IPSec:
- a. improved keys
- Manual IPSec uses fixed keys. In contrast, SKIP uses a hierarchy of
constantly changing keys.
- b. key management
- Manual IPSec does not provide a mechanism by which users can exchange
keys. SKIP implements a key management protocol for Manual IPSec.
- SKIP is described in "SKIP
Encryption Scheme" .
The relationship between the
components of the encryption schemes, as implemented in FireWall-1, is
illustrated in Table
4-1.
Table 4-1
Encryption Schemes
DES, FWZ1 and RC4 are all encryption
algorithms used to encrypt the data portion of a packet.
FWZ (FireWall-1) Encryption Scheme
Under the FireWall-1
Encryption scheme, a message is encrypted with a secret key derived in a secure
manner from the correspondents' Diffie-Hellman keys (see "Diffie-Hellman
Scheme" ). The Diffie-Hellman keys are authenticated by a Certificate
Authority.
Table
4-6 lists the keys used in the FireWall-1 Encryption scheme.
Under this scheme, the number of keys that must be managed
is proportional to the number of correspondents. This is in contrast to other
schemes, in which the number of keys to be managed is proportional to the square
of the number of correspondents.
The TCP/IP packet headers are not encrypted, to ensure that
the protocol software will correctly handle and deliver the packets. The
cleartext TCP/IP header is combined with the session key (derived from the Basic
Session Key; see Table
4-6 for details) to encrypt the data portion of each packet, so that no two
packets are encrypted with the same key. A cryptographic checksum is embedded in
each packet (utilizing otherwise unused bits in the header) to ensure its data
integrity.
Encryption is in-place. A packet's length remains
unchanged, so the MTU remains valid and efficiency is not compromised.
Manual IPSec Encryption Scheme
Manual IPSec is an
encryption and authentication scheme. A Security Association (SA) is associated
with each packet, consisting of:
A 32-bit number, known as the Security Parameters Index (SPI),
identifies a specific SA. An SPI is simply an identifier, assigned by the
correspondents themselves in a particular context, and has no meaning outside
that context.
Encryption
IP packets are encrypted in accordance with
the Encapsulating Security Payload (ESP) standard (RFC 1825, 1827 and 1829). As
its name implies, the ESP standard specifies that the original packet is
encrypted and then encapsulated into a new, longer packet. There are two modes
of performing this encapsulation.
Tunnel Mode
In the tunnel mode, the entire packet
(including the IP header) is encrypted in accordance with the SA previously
decided upon by the correspondents. An ESP header containing the SPI and other
data is added to the start of the packet, and a new IP header is constructed.
The new packet (which is of course larger than the original packet) consists of:
The new packet is
then sent on its way. An advantage of this mode is that the destination
specified in the new IP header may be different from the one in the original IP
header. It is thus possible to send the packet to a host which performs
decryption on behalf of a number of other hosts; the decrypting host decrypts
the packet, strips the ESP and IP headers added by the encrypting host, and then
sends the original packet to its destination. Tunnel mode closely corresponds to
the FireWall-1 encryption model, where gateways encrypt and decrypt on behalf of
other hosts.
Transport Mode (not supported by FireWall-1)
In the
transport mode, the IP header is not encrypted. An ESP header is inserted
between the IP header and the transport layer header. The transport layer header
and everything following is encrypted.
This mode does not increase the length of the packet as
much as the Tunnel Mode does (no additional IP header is added). The encrypted
packet must be sent to its original destination.
Transport mode is not supported by FireWall-1, because it
is designed for end-to-end encryption, and does not allow for the case where
gateways encrypt and decrypt on behalf of other hosts.
Authentication
If authentication is specified by the
SA, then an Authentication Header (AH) is added to the packet, in addition to
the ESP header (and to the second IP header in Tunnel Mode).
FireWall-1 conforms to the Authentication standards
described by RFC 1825, 1826, 1828 and 1852.
SKIP Encryption Scheme
Manual IPSec has two
shortcomings:
SKIP
overcomes these shortcomings by providing a hierarchy of keys that change over
time, which are used to encrypt the connection as well as to implement a key
management protocol. SKIP also includes ESP and AH, and adds its own header to
the packet.
The Encryption Key and the Authentication Key are derived
from the Session Key, which changes at fixed intervals, or when the amount of
data encrypted exceeds a given threshold. The newly changed Session Key is
communicated by encrypting it with the Kijn key, which changes once every hour.
The Kijn key is derived from the Diffie-Hellman shared secret Kij key, using a
cryptographic hash function (see "Diffie-Hellman
Scheme" ). Each correspondent obtains the public part of the other
correspondent's Diffie-Hellman key from a Certificate Authority, that signs the
transmission with its own RSA key.
SKIP includes a protocol (Certificate Discovery Protocol)
for this exchange of public keys. However, this protocol is not supported by
FireWall-1, which uses instead a proprietary protocol for key exchange.
FireWall-1 also supports manual key exchange.
Comparison of Encryption Schemes
Table
4-2 presents a high-level comparison of the three encryption schemes
supported by FireWall-1.
Table 4-2
Comparison of Encryption Schemes
[Top]
[Prev]
[Next]
[Bottom]
Home
info@checkpoint.com
Copyright © 1997,Check Point Software Technologies Ltd. All rights
reserved.